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REMARKS 

Upon entry of this amendment, claims 1-38 are all the claims pending in the application. 
By this Amendment, Applicant amends claims 10, 19 and 28. In addition. Applicant adds new 
claims 29-38. Claims 29-38 are clearly supported throughout the Specification (for example, see 
pages 39-44). 

L Claim Rejections under 35 U.S.C. § 112, second paragraph 

The Examiner rejected claim 28 under section 1 12, second paragraph. Applicant 

respectfully thanks the Examiner for pointing out, with particularity, the aspects of the claim 

thought to be indefinite. Applicant respectfully requests the Examiner to withdraw this rejection 

in view of the self-explanatory claim amendment being made herein. 

11. Claim Rejections under 35 U.S.C. § 102(e) 

Claims 1-28 stand rejected under 35 U.S.C. § 102(e) as being anticipated by U.S. Patent 

No. 6,563,836 to Sikora et al. (hereinafter "Sikora"). Applicant respectfully traverses this 

rejection and respectfully requests the Examiner to reconsider this rejection in view of the 

comments, which follow. 

Claims 1-9 

With respect to method claims 1-9, only claim 1 is independent. Among a number of 
unique features not taught by the prior art reference cited by the Examiner, claim 1 requires 
retrieving the message from the message queue under a control of a second application. The 
Examiner asserts that claim 1 is directed to a method for communication between a first 
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computer and a second computer and is anticipated by Sikora. The Examiner asserts that 
Sikoro's retrieving a transaction message from an engine queue is equivalent to retrieving the 
message from the message queue, as set forth in claim 1 (see page 3 of the Office Action). 
Applicant respectfully disagrees with the Examiner. Applicant has carefully studied Sikora's 
discussion of the transaction messages created by the user queued on a server and which are 
subsequently also queued according to the type of the transaction in an engine queue and is later 
retrieved upon locating the next authorized agent, which is not similar to retrieving the messages 
from the queue where it was first stored as, set forth in claim 1. 

For example, an illustrative, non-limiting embodiment of the present invention discloses 
that if an EIP (Enterprise Information Portal) on a first client computer requests a search from a 
server computer, the result of the search may include a list of items from multiple servers. If the 
second client computer running EIP, would want the same results, it would have to execute a 
second search in a conventional management system, but instead the search results from the EIP 
of the first client computer can now be passed to a second client by using simple messaging 
techniques. That is, the second client computer can retrieve a message containing search results 
from a queue this message was placed into by the first computer. This passage is provided by 
way of an example only and is not intended to limit the scope of the claims in any way. 

Sikora teaches an apparatus for routing transaction messages of different media types to a 
next available agent capable of handling this type of message (see Abstract). In particular, 
Sikora teaches that a customer originates a transactional message such as a phone call, email, 
fax, etc. (col. 3, lines 35 to 43). Each of these transactional messages are stored in transaction 
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processing servers (e.g. server 22 stores emails, server 20 stores telephone call messages). These 
transaction messages can be stored on the servers in queues (col. 4, lines 17 to 41), When a 
transaction message is stored on a server, gateway application creates a routing message to the 
workflow application (Fig. 1; col. 4, lines 41 to 50). 

In particular, the routing message is an event notification informing the workflow 
application that a message has arrived. This event notification may include a unique identifier, 
transaction type, addressor, addressee (if it's an email type of transaction) and a subject, which is 
selected information extracted from the content of the message (Figs. 4 and 5; col. 6, lines 11 to 
58). Based on the information in the event notification, the workflow application determines 
where the transaction message belongs and sends an event notification in a form of a queue 
request to the integrated queue engine (Fig. 3, col. 6, line 59 to col. 7, line 28). Queue engine in 
turn stores the actual transaction message in one of its many queues (e.g. one queue for each 
media type) and may also store data representative of such transaction messages (col. 7, lines 20 
to 25). 

Moreover, the queue engine determines the next transaction to be processed and whether 
the agent is authorized to take the call and if authorized, allocates the transaction message to a 
resource such as an agent (Fig. 6; col. 7, lines 50 to 60 and col. 9, line 23 to col. 10, line 15). 
However, in Sikora, the transaction message is created by the user application (e.g., Outlook) 
and then is sent to a server, where it can be placed in a queue on the server (e.g., e-mail server). 

To meet the recitations of claim 1, the Examiner then alleges that the queue engine retrieving the 

transaction message is similar to retrieving the message from the queue as set forth in claim 1 
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(see page 3 of the Office Action). However, it is respectfully noted that Sikora's queue stored in 
the queue engine is not the same queue as the one stored in the media server (e.g., e-mail server), 
as explained herein above. The queue in the queue engine is created by the workflow application 
and is not the same queue as was created by the first application. That is, the queue accessed by 
a second application (e.g. the agent receives a transaction message from the queue of the queue 
engine) is not the queue created by the first application (storing user created message in a queue 
in one of the media server). 

In short, Sikora fails to teach or suggest that under control of a second application, the 
message queue created by the first application is accessed. Therefore, retrieving a message 
from the message queue under the control of the second application as set forth in claim 1 is 
not suggested or taught by Sikora, which lacks a second application in a second computer 
retrieving a message in a queue created by a first application in a first computer. For at least 
these exemplary reasons, Applicant respectfully submits that independent claim 1 is patentably 
distinguishable from Sikora. Applicant therefore respectfully requests the Examiner to 
reconsider and withdraw this rejection of independent claim 1. Also, Applicant respectfully 
submits that claims 2-9 are allowable at least by virtue of their dependency on claim 1. 

Moreover, with respect to the dependent claim 3, Applicant respectfully points out that 
Sikora only teaches a simple transaction message and an event notification forwarded to various 
server applications. The Examiner alleges that a transaction message type is equivalent to the 
content identifier, as set forth in claim 3. However, Sikora's transaction message comprises of 
text, as acknowledged by the Examiner, (see page 5 of the Office Action). Sikora does not teach 
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or suggest that a transaction message comprises of a type. Instead, Sikora teaches that a 
transaction message is transmitted to a processing system/server dedicated to this type of 
transactions (col. 4, lines 9 to 50). If the message would identify a type, then all transaction 
messages of different types could be stored in one queue (as for example, event notifications 
could be stored in one queue although they relate to different media types). In short, Sikora does 
not teach or suggest that a user created transaction message comprises of a content identifier. 

Moreover, the Examiner alleges that col. 4, lines 17 to 50 of Sikora teach that the 
transaction type comprises of an item identifier and a server name. Applicant respectfully 
disagrees. Col. 4, lines 17 to 50 of Sikora only teach that the transaction message may be stored 
in queues in accordance with the addressee information. Clearly, the addressee information 
cannot be equated with a server name and an item identifier. Moreover, Applicant respectfully 
points out that since each type of transaction will have its own processing system and its own 
gateway application (the system is not an integrated heterogeneous system), there is clearly no 
need for the message to have a server name. As such, Sikora fails to teach or suggest a content 
identifier with a server name . 

In short, Sikora teaches that each media type has its own gateway application which 
forwards it to another queue. As such, no server name is needed to identify the server where the 
transaction message is stored. Therefore, Sikora also fails to teach or suggest this unique feature 
of claim 3. 
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Claims 10-19 

Next, Applicant respectfully traverses this rejection now with respect to the apparatus 
claims 10-18. Of these claims, only claim 10 is independent. Among a number of unique 
features not taught by the cited prior art reference, claim 10 recites: "under the control of a 
second application at the second computer, retrieving the message from the message queue." 
This limitation is similar to the limitation recited in claim 1. Since claim 10 contains features 
that are similar to the features argued above with respect to claim 1, those arguments are 
respectfully submitted to apply with equal force here. For at least substantially the same 
exemplary reasons, therefore, Applicant respectfully requests the Examiner to withdraw this 
rejection of independent claim 10 and its dependent claims 1 1-18. 

In addition, claim 10, as now amended, recites: "a second computer connected to the first 
computer and to the server computer in a datastore management system". Sikora is related to 
allocating transactional messages to agents and has nothing to do with a datastore management 
systems or databases. For at least this additional exemplary reason. Applicant respectfully 
requests the Examiner to withdraw this rejection of independent claim 10 and its dependent 
claims 11-18. 

Claims 19-27 

Applicant respectfully traverses this rejection with respect to claims 19-27. Of these 
claims, only claim 19 is independent. Among a number of unique features not taught by the 
cited prior art reference, claim 19, as now amended, recites: "under control of a second 
application at the second computer retrieving the message from the message queue" and that "the 
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first and second computers and the server are in a datastore management system". These 
Hmitations are similar to the Hmitations recited in claim 10. Since claim 19 contains features that 
are similar to the features argued above with respect to claims 1 and 10, those arguments are 
respectfully submitted to apply with equal force here. For at least substantially the same 
exemplary reasons, therefore, Applicant respectfully requests the Examiner to withdraw this 
rejection of independent claim 19 and its dependent claims 20-27. 

Claim 28 

Next, Applicant respectfully traverses this rejection with respect to indpendent claim 28. 
Claim 28 recites features similar to the features argued above with respect to claim 1, therefore, 
those arguments are respectfully submitted to apply with equal force here. In addition, claim 28, 
as now amended, recites that the first application creates a message, and that when the message 
has text, the text is passed to the second application, and when the message has content 
identifier, an object is forwarded to the second application and when message has no text and no 
content identifier, the second application is notified of an event. Sikora teaches creating a 
convention message having text, which is stored on the server. 

In addition, between the server applications, Sikora teaches event notification messages, 
whereas the client applications (the customer and the agent) do not directly communicate with 
each other. In short, Sikora clearly fails to teach or suggest an application, passing a text 
message, forwarding objects and notifying of an event. Therefore, Applicant respectfully 
requests the Examiner to withdraw this rejection of independent claim 28. 
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III. New Claims 

In order to provide more varied protection, new claims 29-38 are herein added. Claims 
29-34 are patentable at least by virtue of their dependency on claim 28. In addition, claim 35 is 
patentable at least by virtue of its recitation of the body of the message comprising a text length 
value and a content identifier count value. Claims 36-38 are patentable at least by virtue of their 
dependency on claim 35. 

IV. Conclusion and request for telephone interview. 

In view of the above, reconsideration and allowance of this application are now believed 

to be in order, and such actions are hereby solicited. If any points remain in issue which the 
Examiner feels may be best resolved through a personal or telephone interview, the Examiner is 
kindly invited to contact the undersigned attorney at the telephone number listed below. 



Applicants hereby petition for any extension of time which may be required to maintain 
the pendency of this case, and any required fee, except for the Issue Fee, for such extension is to 
be charged to Deposit Account No. 19-4880. 



Respectfully submitted, 



SUGHRUE MION, PLLC 
Telephone: (202) 293-7060 
Facsimile: (202) 293-7860 




Registration No. 39,234 



WASHINGTON OFHCE 



23373 



CUSTOMER NUMBER 



Date: April 23, 2004 
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